Today's world of computer programming offers many high-level programming languages. The flexibility and power offered by programming languages such as C, C++ and Pascal, however, have made these languages very popular among programmers. These programming languages place few, if any, constraints on what a programmer can implement in software, allowing a program to perform virtually any task that may be performed by the underlying assembly language.
One feature of these programming languages which offers significant power and flexibility is the ability to access memory by means of pointers, without restriction. The unrestricted use of pointers, however, invites program bugs which are often difficult to detect and correct with conventional debugging techniques.
A number of software testing and debugging tools have been developed for detecting various memory access errors. For example, the Purify.TM. software testing tool, commercially available from Pure Software, Inc., of Sunnyvale, Calif., and described in U.S. Pat. No. 5,193,180, provides a system for detecting memory access errors and memory leaks. The Purify.TM. system monitors the allocation and initialization status for each byte of memory.
In addition, the Purify.TM. system establishes eight byte buffer zones before and after each block of allocated memory in order to facilitate the detection of array bound violations and similar memory access errors. The status of each byte in the buffer zone is set to an unallocated and uninitialized state. For each instruction that accesses memory, the Purify.TM. system performs a test to ensure that the program is not writing to unallocated memory, and is not reading from uninitialized or unallocated memory.
While the Purify.TM. system provides an effective basis for detecting many memory access errors, it will not detect the common programming error that occurs when a pointer associated with a first block of allocated memory incorrectly accesses a second block of allocated and initialized memory. The Purify.TM. system will only verify that the memory pointed to by a pointer is allocated and initialized, and will not verify that the memory pointed to by the pointer is within the proper bounds that have been established for that pointer.
Other software testing and debugging tools have been developed which have attempted to overcome this limitation. For example, the compiler-based memory access error detection system described in Joseph L. Steffen, "Adding Run-time Checking to the Portable C Compiler," Software-Practice and Experience, Vol. 22(4), Apr. 1992, pp. 305-316, utilizes three words for each pointer, so that the pointer may include information on the valid range of the pointer. Thus, each time a pointer accesses memory, a check may be performed to ensure that the memory pointed to by the pointer is within the proper bounds for the respective pointer.
Many programmers, however, prefer to test and debug their software in an interpreter environment, as opposed to a compiler environment, because interpreter-based debugging is typically more flexible and provides greater assistance during debugging, i.e., by providing sophisticated tracing and other diagnostic techniques. Perhaps even more common is partial interpretation, wherein some files are comprised of interpreted source code while others files are comprised of compiled object code.
However, software debugging tools that operate in a partial interpreter environment, such as the Centerline CodeCenter system, formerly known as the Saber-C.TM. system, commercially available from Centerline Software, Inc., typically have the same limitations with respect to error checking of the compiled object code as the Purify.TM. system discussed above. Specifically, these partial interpretation debugging tools will typically only verify that the memory pointed to by a pointer within compiled object code is allocated and initialized, and will not verify that the memory pointed to by the pointer is within the proper bounds that have been established for that pointer.
As is apparent from the above deficiencies with the prior art, a need exists for a software testing and debugging tool that is capable of performing error detection tasks while executing both interpreted source code and compiled object code. A further need exists for a software testing and debugging tool that ensures that the memory pointed to by a given pointer is within the proper bounds for the respective pointer. In addition, a need exists for a more efficient software testing and debugging tool that reduces the number of duplicative or overlapping pointer checks that are performed at run-time by utilizing information that is derived at read-time or parse time.